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In 1984 the Learning Technology Center (LTC) at Texas 
A & N University negotiated agreements with three K-12 Texas public 
school districts to explore ways that computer technologies could be 
used to assist in managing instructional programs. The intent was to 
establish a field-based research environment in which information 
technologies for educators could be designed, developed, and tested. 
Since the agreements were negotiated before any design specifications 
existed, LTC could only nhare iieas concerning computers' assistance 
in alleviating paperwork associated with planning and evaluating 
instruction, empowering practitioners as decision makers, and tapping 
the power of leading edge technologies. In exchange for the center's 
provision of products and services resulting from the collaboration, 
the participating schools agreed to provide a setting in which a few 
key teachers and administrators could work with products as they were 
developed. The school sites also agreed to allow LTC personnel to 
conduct research on the development, implementation, and use of 
emergent products and services. The collaboration facilitated the 
development of a comprehensive instructional management system now 
being used at several schools. This paper discusses: (1) the 
activities characterizing the partners' relationship between 1984 and 
1989; (2) project development programs; (3) collaboration results; 
and (4) recommendations for ensuring successful future 
collaborations. (Two references) (HLH) 
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Abstract 



In 1984, the Learning Technology Center (LTQ at Texas A&M University entered into 
agreements with rhree K-12 public school districts (alpha sites) in the state of Texas to explore ways in 
which computer technologies could be used to assist in the management of instructional programs. This 
is an area acknowledged in effective schools research as an integral function of school administration. 
The collaboration has resulted in the development of a comprehensive instructional management system 
(IMS) which is now being used in several school sites. In this paper the following items are discussed: 
(a) activities which have characterized the relationship between the^LTC and the alpha sites between 
1984 and 1989; (b) problems that were encountered as the project was being developed; (c) what was 
learned as a result of this type of collaboration, and (d) recommendations for others to consider which 
might help assure successful collaboration. 
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Introduction 

In 19S4, the Learning Technology Center at Texas A&M University entered into agreements 
with three K-12 Texas public school districts to explore ways in which computer technologies could be 
used to assist in the management of instructional programs. The intent of the agreements was to 
establish a field'based research environment in which information technologies for educators could be 
designed, developed, and tested. The agreements were negotiated before any design specifications 
existed. In the beginning, we were only able to share ideas of how^computers might be able to alleviate 
much of the paper work associated with plaiming and evaluating instruction, help empower practitioners 
as decision maters, uid tap the power of leading*edge technologies. 

As part of the collaboration, the LTC agreed to provide (free of charge) any products and 
services that would evolve as part of the collaboration. The alpha sites agreed to provide a setting in 
which a few key teachers and administrators would be able to work with products as they were 
developed - providing continuous input, and making suggestions to LTC personnel for improvements in 
the software. In. addition, the alpha sites agreed to allow LTC personnel to conduct research on the 
development, implementation, and use of the products and services that would be developed. 

The collaboration has resulted in the development of a comprehensive instructional management 
system (IMS) which is now being used in several school sites. In this paper, the following items are 
discussed: (a) activities which have characterized the relationship between the LTC and the alpha sites 
be^ .'een 1984 and 1989; (b) problems that were encountered as the project was being developed; (c) 
what was learned as a result of this type of collaboration, and (d) recommendations for others to 
consider which might help assure successful collaboratirq. 



History of the Collaboration 

In 1983, the Texa> Engineering Experiment Station (TEES), an engineering research arm of the 
Texas A&M University System, funded the creation of a Learning Technology Center (LTC) at Texas 
A&M University. The LTC serves as an entity within which engineers and educators can 
collaboratively work to determine how new technologies can be useful in helping improve educational 
systems and solve problems in education. During the Center's first year, focus was on development of a 
research agenda. Durin;; this period, TEES hosted leading researchers in educational technology, and 
funded visits to various research sites across the nation to deternrine, as closely as possible, what other 
activities were occurring. These activities were undertaken to avoid reinventing or duplicating 
technology or applications ihai others were already developing. 

From the research, we deterniined that there were large-scale efforts to develop micro-based 
applications for administrators (e.g., scheduling packages, inventory co:urol, budgeting, and decision 
support systems) and for students (e.g., computer assisted instruction packages and integrated learning 



systems), but that with the exception of a few grade book and graphic development packages, no efforts 
were underway to use the new microcomputer-based technology to empower teachers. In fact, in many 
of the developing applications, teachers were being bypassed. 

In 1984, the staff of the LTC began visiting with practitioners about how computer technology 
might be useful as an information management tool if that tool were designed to give teachers access to 
the plethora of information that they need when th^ plan and evaluate instruction. The idea was 
enthusiastically received, and the LTC began pursuing that agenda. 

To enable us to develop the new technology in a way that would be immediately practical and 
useful by practicing teachers and administrators, we decided to not only conduct extensive needs 
assessment activities in the field, but to also develop the product in the Held. These decisions required 
the development of a close collaboration between the LTC and practitioners in the environments within 
which, it was hoped, the technology wouid be used. We realized that in order to do a thorough and 
thoughtful job at designing, developing, and testing the new technology, long-term commitments would 
be required. We also felt that it was important to establish collaboratives with more than one district 
and that the districts be of different sizes because: 

(a) technology, whenever .. is successfully implemented in in organization^ impacts and alters 
that organizatioi, and size is one of the factors which affects the nature of the changes; and 

(b) the processes involved in planning and evaluating curriculum and instruction vary in major 
ways from small to large districts. 

By Spring of 1984, we had negotiated long-term research and development agreements with 
three K-12 school districts. (These districts were designated as alpha sites.) The smallest district had a 
student enrollment of less than 400. The enrollments of the other districts were around 3,000 and 
12,000 respectively. As a part of the contracts, the LTC agreed to give the alpha sites whatever 
products and services might evolve from the collaboration. In exchange, the alpha sites agreed to 
provide staff and equipment that were necessary in order to test and evaluate the products and give 
feedback to the LTC to assist in design and development work. Additional features of the agreements 
were designed to facilitate on-site research for doctoral-level students at Texa^ A&M. Internship 
opportunities were included as an option. 

Immediately after the agreements had been negotiated, staff of the LTC and students in the 
Educational Technology program at Texas A&M University visited each of the alpha sites and conducted 
a series of needs assessment activities. The purpose of the needs assessment was to determine, from the 
teachers' perspectives, the ways in which their jobs could be improved and what would be needed for 
ihem to feel more enthused about teaching. In other words, how can teaching be made more 
professionally rewarding? In the two smaller districts, & nominal group technique was used with small 
groups of teachers, in the larger district random interiews and a survey instrument were used. 

We felt that it was important for the teachers' responses to be free of any artificial bias^ so we 
tried to hide the fact that we were interested in determining how computers might be used to help 
improve education.^ As an aside, it is important that the reader understand that the needs assessment 
activities were conducted about the same time that the Texas Legislature was passing HB 246 the intent 



^ Our purpose in this paper is to discuss the nature of the coUaboraiion, not the results of the 
needs assessment nor the products which have evolved. If you are interested in obtaiaing additimal 
information in either of those two areas, please write oi call the authors. 
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of which wa5 to require teachers to demonstrate linkajjes between their daily instruction and a set of 
state curriculum guidelines (the essential elements of instruction). 

As a result of the data that were obtained from the needs asse<isment activities, a design was 
conceptualized which would involve the use of microcomputers to assist teachers and administrators as 
they plan, manage, and evaluate instruction. We wanted to design a system which could be used to 
increase teachers' ability to be accountable to the public and to the state regulatory bodies, but did not 
want the system to restrict creativity nor remove local control. We felt that it was possible, using new, 
powerful hardware/software systems to design support technologies which could bj used to increase 
teachers' abilities to manage diversity and increase their decision-making skills while automatically 
maintaining suCGcient audit trails which could be used for analysis of thr.se decisions and the generation 
of the accountability reports. 

During the Summer of 1984 we began evaluating various hardware platforms and the set of 
relational database management systems (RDBMS) which were just beginning to become available for 
microcomputers. In collaboration with graduate students in computer science, we acquired around 
twenty such systems for evaluation. The results of our evaluation *re reported elsewhere (Chen and 
Burger, 1986).'. We selected two RDBMSs, one which we felt would be good for the development of a 
proto^e (prototype RDBMS)^ the other which would be good foi^the development of the final product 
(product RDBMS). 

By late summer, 1984, we had begun developing a prototype, and a teacher began entering 
curriculum into the system. Despite the fact that the prototype was awkward to use and was not fully 
developed, a teacher in one of the alpha sites began using the IMS to build an electronic database of 
her curriculum and to align that curriculum to the newly released state guidelines for instruction. This 
teacher had never used a computer before. This experience gav? us our first lessons in how to improve 
the prototype and what new features and capabiUtirs would be needed. The prototype, at that timo, was 
only a vehicle which could be used to 'capture' a school's curriculum, help align the local curriculum to 
state guidelines, and print curriculum documents. 

During the next two and one half years, we continued to work with teachers and administrators 
in the alpha sites developing the prototype and e>ploring different implementation strategies. As the 
prototype was being developed, we began developing the 'real' IMS using the product RDBMS. The 
product RDBMS was :nuch more difficult to use, but was much more powerful, flexible, and responsive 
than the prototype RDBMS. Computer Science students were hired to develop the IMS using the 
product RDBMS. Near the end of the two and one half years (early, 1987), we 're-engineered' the 
softwckre that was being developed on the product RDBMS. The change (which involved a new database 
structure as well as a completely new user interface) was made in order to utilize the new capabilities 
that became available in a new relej^^e of the RDBMSs we were using and because we itad hired new 
programming staff who had learned the capabilities of the product RDBMS and were using new . 
approaches to software development. 

During the Fall of 1988, we stopped developing the prototype, pulled ii from the alpha sites, 
and convened the alpha sites to the final product. Even though the product was not as fully developed 
as was the proto^e, its flexibility, reliability, and speed were superior. The practitioners were more 



' It is important for the reader to understand that our evaluations of the relational database 
management systems were done in the context of our design specifications, and were not done in order 
to provide a general statement about the rv-iative worth of each one. Other publications do that well 
(e.g., trade journals such as Info-World. Bvte. or PCWeek). These publications and others were 
consulted as part of our own evaluation. 




pleased with the new product than they were with the prototype. At that time, we recruited two beta 
sites which, we hoped, would help us understand some of the issues that would be involved with 
implementing the IMS in K-12 emironmenis. We are hoping to continue working with these five 
schools (the three alpha sites and i\t two beta sites) over the next several years as we proceed with 
research activities and product development. 

Research topics which we are interested in pursuing include: (a) how can the data that are 
generated through the use of the IMS be used to improve instruction and instructional programs; (b) 
what are the impacts that the use of the IMS has on teachers and administrators (in altering their skills, 
knowledge, or how their time is spent, etc.) as they work to improve instructional programs; (c) what 
are the best ways to implement this type of technology in schools; and (c) and what types of changes 
occur (or are possible) in schools when comprehensive IMSs are used. 

By Spring of 19S9, we felt we had a product that could be mailed to districts with no 
accompanying support person, and which could function reliably and be used easily, even by novice 
computer users. By the Fall of 1989, all of the alpha and beta sites had expanded their use of the IMS 
by implementing it on more workstations and making those workstations available to more teachers. 
Each of the districts continues to use the system to develop and modify their curricula, and several 
teachers are using the IMS regularly to develop their lesson plan.s. \ 

As of this writing, the product continues to undergo revisions and improvements based on 
feedback from the field. We have released Module I which assists in the design, development, 
alignment, and maintenance of curriculum and in the design, development and monitoring of lesson 
plans. Several new districts have either purchased the IMS or have committed to purchase. In addition, 
we have established or are in the process of establishing collaborations with professors in about a half 
dozen uni\'ersities who want to install the IMS and use it in their programs to train preservice and 
inservice practitioners and as a basis for service and research in their service areas. 



Problems 

As one might expect, everything has not gone smoothly over the past five years as a result of 
our commitment to developing a camprehensive product in a collaborative effort. Most of the problems 
that we encountered, however, are ones which, if anticipated, could be avoided or solved. In this paper, 
discussion is limited to the four predominant problems which probably are going *o buffet any 
substantive collaborative efforts of this type. They are discussed in no particular order and are followed 
by a set of recommerlations. 

There was, in our work with the K>12 districts, a general tendency to promise more than what 
we were able to deliver. We found it difficult to maintain a balance between establishing and 
supporting enthusiasm for, and commitment to, our new (not yet developed) innovations, and mollifying 
those expectations so that they were in-line with reasonable development of the inventions. There were, 
in our case, several reasons why this was a problem. Among them were; inaccurate estimate for the 
time required to do software development, changes in organizational support for our research efforts, 
lack of continual communications, and incomplete testing of the software by both groups. 



Inaccurate Estimates 

New technologies are seldom developed 'on schedule' because with their development, new 
ground is being broken. Timelines for development are vague and difficult to estimate. This is true 
especially in prototyping environments, because in those development models, one does not know what 



the product will look like until it is developed. One of the lessons that we learned in the first year of 
the collaboration was that our most optimistic estimates for development of software were less than one 
half of the time that was aaually required. 

In addition, both of the RDBMSs that were selected were constantly evolving and becoming 
more powerful. (For example, our prototyping RDBMS went through five major upgrades during the 
years in which we were using it) New features enabled us to make significant design changes that 
resulted in dramatic improvements in the IMS. As a result of new capabilities of the product RDBMS 
software, we undertook a virtual redesign of the user interfaces. 



Changing Organizational Support 

In most coUaboratives, the collaborating groups are very small subsets of lar^j organizations. 
Incidents occur in the larger organization over which the collaborative groups have no control. 
Neverthdless, many of these incidences impact the collaboration Unforeseen budget cutbacks, political 
struggles, changes in administrative staff, alterations in evaluation or assessment criteria are only a few 
examples of incidents which can occut inaependently of whether or not a collaborative arrangement 
exists withm a subsystem of a large organization. Those events cai\ and do affect each party • the one 
in whose organization the incident occurs and the one who is on the other side of the collaborative 
arrangement For example, in Texas, the dramatic and rapid decline in oil prices during the first half of 
the 1980's affected eveiyone's budget As a result, from 1985 on the LTC operated at roughly one half 
of the budget that we originally felt would be needed in order to sustain product development and 
support for the collaboration. Reduction in staff therefore, slowed the development of the IMS and 
made it difGcult to develop produa on schedule or test it as thoroughly as needed. 

Research priorities at the upper levels of an organization's administration might also impact 
support for a given collaborative arrangement if those priorities are not consonant with the goals of the 
collaboration. For example, we found that our desires to conduct field-based, applied research and our 
feelings that those efforts would contribute to improvement of education was in conflict with the 
University's tenure and promotion policies which functionally recognized published articles in refere>3d 
journals as being the 'only* acceptable means whereby one could establish professional credibiliQr. 
Though the policy has not impacted our research, it has impacted us as individuals. That is, we have 
chosen to proceed regardless of how that policy has affected our professional positions within the 
university structure. 



Maintaining Communications 

The third major problem was that maintaining sustained communications was difficult 
Participants in both collaborating groups had obligations to the broader organization. Many of those 
obligations did not directly benefit the collaboration. Because of that, our collaborative efforts were 
always diluted with other commitments. When we did not maintain a high level of communications and 
support, the collaboration was perceived to get in the way of the regular daily activities of the 
practitioners. We would have liked to have engendered, in the participants at the alpha sites, a 
perception toward the collaborative activities within which collaborative activities were viewed as an 
integral part of their daily activities. 

Realizing the importance of communications, we established an electronic mail (E-mail) link 
between the LTC and the alpha sites. E-mail was selected as a communication vehicle because of two 
main reasons. First, it takes one half hour to get to the nearest alpha site, and three hours to get to 
the furthest alpha site, so on-site visits needed to be carefully planned and coordinated with other 




obligations. Second, because of other obligations, direct, synchronous communications were not always 
possible. 

The E*mail system which was originally used was a mainframe*based system. This meant that 
we had no control over system maintenance nor over the procedures that users n>«ded to learn in order 
to successfully interact with it. We provided on*slte training for the alpha site personnel who would be 
using it. The interface was changed two or three times without warning, however, and the personnel in 
the alpha sites became discouraged, and iheir use of the system dropped to zero. To solve the problem, 
we purchased our own remote bulletin board system (RBBS), installed it on an old micro computer in 
the LTC and kept it operational 24 hours a day. We also acquired a software package that would let us 
remotely diagnose, operate, or monitor computers at the alpha and beta sites. Though not used 
extensively, these two packages have saved us a considerable amount of time and expense and have 
served to strengthen the communication ties between our collaborating groups. 

In addition to facilitating electronic communications, an LTC staff member was assigned the task 
of working with the alpha sites. That person scheduled regular monthly trips to two of the three sites. 
(In the second year of the collaboration, the largest district hired an LTC staff member as an intern 
who served as a liaison to the project. The intern was to install new software, conduct training, 
Cacilitate data entry, and coordinate district planning for the project Gradually, however, other demands 
placed on his time and talents by several other technology projects which were being implemented 
reduced his effectiveness as a project liaison.) 



Unreliable Software 

Even in a development mode» novice users expect products that work and work well. We found 
that, many times, in an effort to r^sure the pnctitioners that we were making progress and solving their 
problems, we released produa too early. Not many things are more frustrating to a practitioner v.'ho is 
excited about the potential of a new tool and then finds that it is too difficult to use or does not work 
properly. Producing b;:g-free software is a very difGcult task espedaMy in a prototyping environment, 
without the support of rapid-prototyping environments (Hekmatpour, 19S7), because it is the nature of 
the project to evolve based on user input and based on field observations. Quite frequently, we found, 
changes that were made to accommodate suggestions or to fix a problem, affected other, previously 
working, components of the software. It was almost impossible for us, due to resource limitations, to 
thoroughly test each version prior to release and maintain a reasonable software development schedule. 

Later, in the project cytlt, we were able to produce a product which, though not complete, 
reliably and easily accomplyhed most of what the practitioners wanted. When we had achieved that 
level, we were aMe to 'freeze' product releases until thuy had passed through at least two levels of 
review and testxng in the LTC. Nevertheless, product, seldom work in the field the same way thai they 
work in the development laboratory. To h-^lp us simulate field conditions in the LTC, we enlisted 
student volunteers (who were up to that point unfamiliar with the software) to wor'^c with the system 
and evaluate the documentation. Thei: insights as novice users were invaluable in helping us to 
establish quality and deliver products which work^ d under field conditions. 



Recommendations 

The most pervasive and difficult problem we encountered as we worked collaboratively with K- 
12 practitioners to design and develop the IMS was maintaining the expectations of the practitioners 
such that they were both committed to the long-term objectives of the project and yet were willing to 
put up with problems as those long-term objectives were being pursued. We found that our enthusiasm 
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about the project and our interest in maintaining commitment in the alpha sites tended to raise the 
expectations of the K-12 particir-ants to a point that exceeded our ability to perform reliably. 
Confidence in the work of the collaborative is a fun.lion of communication a;id quality control 
mechanisms. In order to be able to make accurate projections and avoid embarrassment, it is very 
important to keep in close contact wiih other organizations which can influence the success of the 
collaborative. 7or example, when the collaboration involves software developnT>)nt that depends on 
projects, softvi'are development houses vendors and build collaborative activities o keep up to date with 
software changes and new expected capabilities. 

We found that it was impc;tant to do more than just facilitate communications. The best 
progress was realized when we were able to provide regular in-depth support of those who were in the 
alpha sites, and when we were able to periodically encourage them to maintain coi.tinued involvement 
When they realized that we depended on them for feedback, and that their recommendations were 
crucial for the development of the project, ihey responded positively. When support aud persuasion 
were not consistent, feedback fircm the field slowed. 

We learned that collaborative efforts that are developed within larger organizations need to 
explicitly contemplate the stated goals and missions of the larger organization. Unless the nature of the 
collaboration is clearly stated and pro^rammaticaily supported, colii^boratives are very v\ilnerable and 
subject to the vagaries of cultural and economic pressures, organizational politics, and the caprice or 
reorganization of upper-level administrative stafiL We do not intend to say that collabonuives, as 
components of very large organizations, are either inadvisable or impossible to sustain. Rather, those 
who are participating in the collaborative must make concerted efforts to understand which variations in 
the larger organizations can and m-ght impact the nature of the collaborative, and plan foi those 
contingencies. If substantial support is not obtained at the highest levels of both organizations within 
which the collaboration is to occur, then when the initial excitement shared by the participants fades, 
and the firuits of one's labors are not immediately apparent (or are taking longer than originally 
estimated), there is a danger that tlie collaborative efforts diminish and it gradually fades into 
nonexistence. 

Do not be a&?>id to hold each other accountable but do so within the context of a professional 
and non accusatory atmosphere. Collaborntors are companions, not competitors. Establish formal 
iticchanisms within which free and open communication between collaborative bodies can occur and 
proactively encourage on-going communication between participants by idei. iifying and removin;; barriers 
which prevent or discourage it Encourage explicit discussion of expectations, perceptions, and 
performance. Be sensiiive to the demands placed on each other by the respective institutions. As much 
as can be possible it is important to consider the duties which compete for time and resources of the 
participants and make accommodations for them during tl.: planning and negotiations process. The 
plans for the collaborative should include procedures which can systematically be used to evaluate the 
products and processes associated with the collaborative. 

Summary 

In this paper, we have taken a backward glance at our experiences as a result of collaborating 
with K-12 districts in the design, development, and testmg of an instructional management s>'stem. In 
spite of the problems that are presented here, the collaborative has been extremely productive for all 
who have been involved. Each of the alpha sites have extended their commitments to the project and 
will be implementing the IMS at building levels in multi-user environments during Fall, 1989. Giver, 
that considerable t^me has passed between the initial agreements and a truly functional product, we 
consider the fact that the technology is being incorporated into the fabric of the K-12 settings as a 
measure of success. The collaborative efforts will extend into the future as we continue development of 
the IMS and conduct research on its implementation and use. 
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As organizations become more dependent on other groups for information an'* resources, 
collaborative arrangements will, we feel, become more and more important. Organizations which 
collaborate with other, dissimilar groups have a greater chance to become more responsive to a changing 
environment than those which do not In addition to examining literature which features studies of 
collaborations, those who are considering collaborative efforts might find results from research projects 
which have studied the dynamics of complex organizations useful and applicable. Having had the 
fortune of working with three K-12 districts over the past five yeai^, we have learned a great deal. As 
with most activities, there is not a set of procedures which, if followed, will guarantee problem-free 
collaboration *)etween organizations. If members keep a continued focus on the purposes for which the 
initial collaboration was pursued, then disturbances can be identified and removed or tolerated while 
they are being pursued. 
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